IBIS Macromodel Task Group Meeting date: 05 December 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad reviewed the schedule for upcoming ATM meetings. The group plans to cancel the meetings on December 26th and January 2nd. All other meetings in December will be held as usual. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Michael M.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD189 - Groups/Sets - Walter: [Reviewing his proposal - first sent in an email to the Interconnect group on November 21, "Updated Interconnect Model Group rules, including change to [Interconnect Model Set] ] - [An updated version of the proposal, including corrections from the meeting and introducing a new [Interconnect Model Group] Sub-Param "Group_type", was sent out to ATM and Interconnect by Walter on December 5 (after this ATM meeting)] - refer to this email. - Replace the last paragraph of [Interconnect Model Set] Usage Rules with: An [Interconnect Model Set] contains a list of [Interconnect Model]s that have a logical association such as: * All models in a bus (e.g., DDR4, or PCIeG3) * PDN Network * All I/O models between Pad and Pin * All I/O models between Buffer and Pad * All uncoupled models * All coupled models - For example an EDA tool may do an S-parameter for a PCIeG3 bus, and maybe a DDR4 bus, but not do S-parameters for the other parts. - PDN is an obvious one where your models may come from a different tool. - I/O models between pad and pin are what we typically call package models and may come from a package design tool. - I/O models between buffer and pad might come from an Si design system. - Things could be partitioned other ways, but often it's by the tool that made the model. - Change [Interconnect Model Set Group] to [Interconnect Model Group]. - This has already been done. - New paragraph and rules introduced for the [Interconnect Model Group] section. - Discussion: Walter noted that [Interconnect Model Set]s are collections of models. [Interconnect Model Group]s contain one or more [Interconnect Model Set]s, and we have enforceable rules on the collection of models in a Group. - For non-aggressor (victim) I/O Pin_name terminals: - If a pin to buffer model exists, then it's an error if there is also a pin to pad or pad to buffer model. - It's an error if two (or more) models have a buffer terminal with the same Pin_name. - It's an error if two (or more) models have a pin terminal with the same Pin_name. - This does not apply to pad terminals, because in a pin to pad and pad to buffer modeling scenario two models may refer to the same pad. - If there is a pad to buffer model and no pin to pad model: - Use the legacy package model. - Bare Die IBIS files shall have legacy package models with R=0, L=0, C=0. - Note: This rule modified in the subsequent email introducing "Group_type". - For pins appearing as aggressors (and as aggressors and victims), the errors noted above are reduced to warnings. This is because the same pin may appear as an aggressor in multiple models. - For models with rail voltages: - If a signal name is only on pin terminals, or only on pad terminals, or only on buffer terminals, then these terminals are used to defined the references for the interconnect model. - In this case, it is not an error to have multiple models with a connection to these buffer terminals or rail terminals. Walter noted that he thought these rules were straightforward and easy to check. Arpad asked Walter to send out the updated version of his proposal. As noted above, Walter did so. - Bob: [Reviewing his proposal and power point presentation from an email sent to the ATM group on December 5, "BIRD185.5X Groups and Sets Discussion" (typo in email subject - should have been 189.5)] - [Reviewing presentation .docx] - In place of the [Interconnect Model Group], introduced 3 different Group keywords depending on the boundary of the contained interconnect model(s). - [Interconnect Model Group] (full pin to buffer) - [Interconnect Model Buffer Pad Group] (on-die interconnect) - [Interconnect Model Pad Pin Group] (package model) - This makes it clearer to the EDA tool what is contained in the Group. - The model maker might, however, decide to wrap a package Group (Pad Pin Group) in a full [Interconnect Model Group] keyword instead, if they know the on die is just a short and they want to make the EDA tool's life easier. - I note that I/O paths are easy, but rail paths can be more difficult because of our options. - [Reviewing his .pptx presentation] - [slide 2] - You could use all 3 of these Group keywords for the same group of pins. - [slide 3] - Modification of Michael Mirmak's figure from the BIRD itself. - A single [Interconnect Model] never has pin, pad, and buffer terminals at the same time. It can connect to any two of the three. - [slide 4] - As Walter noted [Interconnect Model Set]s encapsulate [Interconnect Model]s. - If we encapsulate just pin to die pad models (like a package model) then the boundary is clear with this proposal. - Similarly, for buffer to die pad the boundary is clear. - [slide 5 and 6] - Alternate configurations of [Interconnect Model Set]s. - Walter: Looking at this slide, say this is for pin 17. - In the same set, can I have a model for pin 16 that just goes from pin to die pad? (there is no path from pin to buffer on that pin 16) - Bob: In a Set, yes that's okay. - When I get to Grouping of sets, that would be an error. - Who are we supporting that wants to do that? - Walter: I can answer that question (deferred to end of Bob's presentation). - Bob: - [Reviewing presentation] - [slide 7] - Probably should support this configuration. - So far I've shown the choices for Sets that I think make sense. - Now similar drawings with respect to Groups including Sets. - [slides 8 - 11] - Standard configurations. - [slide 12] - Within a Group, do we support a combination of some Sets that go from pin to buffer with other sets that split the path into pin to pad and pad to buffer? - I think we do. - [slide 13] - I think there's nothing illegal about this. A set S1 could go from buffer to die pad on one set of pins and be used from die pad to pin for another. - [slide 14] - I favor not having implicit short-circuit rules. - This makes it error prone and hard to check. For example, are models from pin to pad missing by mistake or were they left out on purpose? - [slides 15 - 18] - Mixed boundaries of Sets within the Group. Some paths go all the way, some only part way. - I would call this an error. - I don't think we should default to a short or some legacy RLC model. - EDA tools might fill the void differently. - [slides 19 -25] - [Interconnect Model Set] boundary configuration examples. - [slide 26] - [Interconnect Model Set] and [Interconnect Model Group] boundaries. - Group boundaries easy to check with this proposal. - Prevents possible mistakes of missing Sets or wrong Sets. - Set boundaries may be worthwhile. - Prevents possible mistakes of missing models. - Typical practice would be to have "same-boundary" Sets and Groups. - Walter: I have some high level questions. - [Interconnect Model Group] is a list of [Interconnect Model Set]s. - [Interconnect Model Set] is a list of [Interconnect Model]s. - The original concept was that a [Component] has multiple Groups and the user selects one to perform a particular simulation. - Is that still true with your proposal? - The user only selects one? - Bob: Yes. - Walter: Then all Groups should be between the pin and buffer. - If you're only choosing one, how can you break them down into different types of Groups based on boundary, when the user only chooses one so it must go all the way from pin to buffer. - Arpad: (to Walter) Randy had said we might want just bare die or models with just package alone (no on die). Perhaps that's why we need to discuss this? - Walter: Those might be put into different Groups, but the user still just chooses one group. - We still have the concept that when one does a simulation they are only using the models from one particular Group? - Bob: Yes. - I allow a bare-die group, or a package only group, or a full simulation, but you only choose one group. - We clearly identify by the keyword name what the Group contains. - Walter: Isn't that equivalent to every group having a description that explains what it contains. The EDA tool could display that to the user. - Bob: I prefer to have it built in to the keyword. - Descriptions aren't parseable. - For example, it's clear we support a bare die group with this proposal. - Walter: A bare die model is just one that has an IBIS [Component] which just has R,L,C zero for all the pins. - Bob: My separate keyword names makes it clear when you're doing bare die. - Walter: We are asking the user to select a group. - Whether they do it based on a keyword or based on a text description, isn't it equivalent? - You would like to qualify a Group with separate keywords. - I would prefer not to do it with the Group name, but instead to have a Sub-Param and optionally a description. I think you might end up with a long list of choices for the Sub-Param, but that's okay. - If we added a new Sub-Param to the [Interconnect Model Group] keyword that specifies "this is a die only Interconnect Group", which means you then short everything from die pad to pin instead of using the package model, then aren't your proposal and mine equivalent? - Wouldn't all the rules in my proposal still apply? - Bob: Yes, they're sort of equivalent. - I originally considered a Sub-Param, but I think having separate top level keywords makes the selection more clear and the checking easier. - Arpad: We started by saying we only want the user to make one Group selection. - Have we come back to the point that that user has to make multiple selections again? - Bob: The user chooses 1 Group, but chooses a different Group depending on what they want to simulate. If you want to do full path, or bare die, then the model maker provides different Groups for each. - Arpad: Thank you all for joining. AR: Walter to send out updated version of his proposal. ------------- Next meeting: 12 December 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives